Skip to content

fix(web-client): follow the rc.6 account and note file format - #414

Open
WiktorStarczewski wants to merge 4 commits into
nextfrom
wiktor/protocol-0.17.0-rc.6
Open

WiktorStarczewski wants to merge 4 commits into
nextfrom
wiktor/protocol-0.17.0-rc.6

Conversation

@WiktorStarczewski

Copy link
Copy Markdown
Collaborator

Client PR: #2594

Account and note files follow protocol 0.17.0-rc.6. miden_client::notes is gone, AccountFile fields are private, and both files encode as protobuf.

  • NoteFile comes from miden_client::note.
  • Import uses account() and into_parts().
  • serialize / deserialize call to_bytes / try_from_bytes. Bytes from 0.17.0-rc.1 do not decode.

Cargo.toml stays on published miden-client 0.17.0-rc.1. CI injects the linked head. Do not merge on the readiness gate alone: that gate goes green when rust-sdk #2594 reaches next, while this tree still does not compile against the published client. Bump the client pin to the release that contains #2594 before merging.

Reviewers: the byte-format break is the part worth your time.

AccountFile fields are private and both file types encode as protobuf.
NoteFile now comes from miden_client::note.
@github-actions

Copy link
Copy Markdown

🔗 Linked client PR: 0xMiden/rust-sdk#2594

Field Value
Patched at 0xMiden/rust-sdk@jmunoz-protocol-0.17.0-rc.6
Pin (head sha) 1e45cfda68993a3f6807f6ac9d25bfc66564e957
Upstream state open (merged: false)

This run is testing against the linked PR's head. The published artifact will use the canonical miden-client source — CI on main/next does not auto-patch.

Local-dev parity:

scripts/dev-with-client-pr.sh 2594    # apply the same patch locally
scripts/dev-with-client-pr.sh --clear                            # remove it before commit

The node stayed on rust-sdk v0.17.0-rc.1 while the client was built from
the Client PR marker, so execution looked up a protocol config the store
did not have. The rc.2 sequencer also reads its batch-builder wallet from
the environment, which older nodes ignore.
@github-actions

github-actions Bot commented Sep 22, 2026

Copy link
Copy Markdown

➖ WASM proving — No significant change (largest prove / consume / ecdsa-k256-keccak -0.36%, floor ±1.90%)

Head 80f39fa
Base 85a73e3 (next)
Method mean of per-rep fastest, 6 reps × 3 warm proves, release / mt, 8 threads on warp-ubuntu-latest-x64-8xlower is better
Workload 1 benchmark (ms) — prove / consume / ecdsa-k256-keccak
Benchmark Base (ms) Head (ms) Δ Δ %
prove / consume / ecdsa-k256-keccak 2,841.8 2,831.7 -10.1 -0.36%
Methodology and raw samples
  • The timed interval is the proveTransaction call on a client constructed without a web worker. Prover construction, transaction execution, the faucet draw and the production worker round-trip are outside it, so a change confined to any of those does not move this number.
  • The run configuration below — runner, profile, variant, thread count, repetition and prove counts — is reported by the benchmark job, which runs from this pull request's own code. It describes what that job says it did. Every figure and every verdict above is recomputed here from the raw samples.
  • Each benchmark keeps 6 reps × 3 warm proves on warp-ubuntu-latest-x64-8x (8 threads, release / mt). One extra repetition and the first prove of every page run first and are discarded.
  • The reported figure is the mean of each repetition's fastest prove. Within one repetition every prove is bit-identical work, so interference — which only ever adds time — is all that varies, and the repetition's fastest prove is its best observed warm prove — a lower-tail statistic, not a measured "clean" cost, and so blind to a regression that leaves the best case alone (see the mean cross-check). Across repetitions the faucet differs, which shifts the proof-of-work grind, so averaging the per-repetition minima shrinks that lottery — it averages the grind down rather than cancelling it, because each side draws its own.
  • Measured over six calibration runs of identical binaries, this estimator holds a standard deviation of 1.79%, against 2.96% for a global minimum and 5.39% for a plain median.
  • A movement is only called significant when it clears the noise floor and no repetition's paired difference contradicts the direction, with a majority of repetitions positively agreeing. Base and head run interleaved within a repetition, so the pairs saw the same machine; a movement whose repetitions disagree is reported as unresolved rather than as a result. Runs shorter than 6 repetitions are never called significant — the floor is calibrated at that count and does not transfer below it.
  • Base and head are driven one prove at a time, alternating, with the order flipped every prove. Running each side's batch back to back let the second side pay a consistent penalty — measured at +1.19% before this was fixed, which is a bias no number of repetitions removes.
  • A wide gap between the reported figure and the max has two causes and the samples below do not separate them: interference within a repetition, and the proof-of-work grind differing between repetitions. Neither invalidates the comparison — both sides ran interleaved on the same machine — but a gap much wider than usual is worth a second look.
  • Base and head are measured in the same job on the same runner, so runner-to-runner drift cancels out. The base dist may have been built by an earlier run of this workflow and restored from cache — the cache key covers the toolchain and the build commands, so the bytes match what this run would have produced.
  • Δ % = (head − base) / base on that figure. Lower is better for every benchmark in this suite.
  • Every figure above is recomputed here from the per-rep samples in the artifact; the summary statistics the bench script reported alongside them are not used.
  • The ±1.90% threshold is calibrated on warp-ubuntu-latest-x64-8x (2026-08-27): 30 runs of one build against a copy of itself, at 6 repetitions, gave a standard deviation of 0.62% and a largest movement of 1.17%. It is 3σ (1.85%) rounded up, which here is the procedure rather than a deviation from it: the largest movement across those 30 no-change runs stayed below 3σ, so nothing observed argues the tail is heavier than normal. How this is measured.
  • Full machine-readable results are attached to the run as results.json.

Per-rep samples

  prove / consume / ecdsa-k256-keccak
  base rep  1: 2,845.8, 2,853.0, 3,038.7
  base rep  2: 2,891.8, 3,112.2, 2,890.1
  base rep  3: 2,846.5, 2,869.4, 2,931.1
  base rep  4: 2,854.8, 3,067.7, 2,810.1
  base rep  5: 2,881.5, 2,845.0, 2,932.3
  base rep  6: 2,817.2, 2,813.5, 2,834.2
  base median 2,862.1 ms  min 2,810.1  max 3,112.2
  head rep  1: 2,895.5, 2,826.3, 2,915.7
  head rep  2: 2,888.3, 2,854.1, 3,045.9
  head rep  3: 2,868.7, 2,824.6, 2,862.4
  head rep  4: 2,959.4, 2,843.3, 2,857.4
  head rep  5: 2,851.6, 2,851.2, 2,830.2
  head rep  6: 2,811.8, 2,917.1, 2,900.7
  head median 2,859.9 ms  min 2,811.8  max 3,045.9

🔺 slower beyond the noise floor · 🔻 faster beyond the noise floor · ❔ no verdict — see the heading and notes above · ➖ within the noise floor


Generated by bench run 35755881526 for 80f39fa. This comment is informational only and never blocks merge.

Node 0.17.0-rc.2 exits when fee-collector.mac is missing. The linked
rust-sdk start script does not create or deploy that account.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant